Routing messages

ABSTRACT

This invention relates to a method of routing for a message via an IMS system is disclosed. A message is received at an ICSCF. Address information is obtained for one of an application server, server or gateway for which said message is intended. The message is sent to said application server, server or gateway in accordance with said address information.

FIELD OF THE INVENTION

The present invention relates to the routing of messages, and inparticular but not exclusively in an IMS system.

BACKGROUND TO THE INVENTION

The introduction of Third Generation (3G) communication systems willsignificantly increase the possibilities for accessing services on theInternet via mobile user equipment (UE) as well as other types of UE.

Various user equipment (UE) such as computers (fixed or portable),mobile telephones, personal data assistants or organisers and so on areknown to the skilled person and can be used to access the Internet toobtain services. Mobile user equipment referred to as a mobile station(MS) can be defined as a means that is capable of communication via awireless interface with another device such as a base station of amobile telecommunication network or any other station. Such a mobileuser equipment can be adapted for voice, text message, datacommunication or multimedia communication via the wireless interface.

The term “service” used above and hereinafter will be understood tobroadly cover any service or goods which a user may desire, require orbe provided with. The term also will be understood to cover theprovision of complimentary services. In particular, but not exclusively,the term “service” will be understood to include Internet multimediaservices, conferencing, telephony, gaming, rich call, presence,e-commerce and messaging e.g. instant messaging.

The 3G Partnership Project (3GPP) is defining a reference architecturefor the Universal Mobile Telecommunication System (UMTS) core networkwhich will provide the users of UE with access to these services. ThisUMTS core network is divided into three principal domains. These are theCircuit Switched domain, the Packet Switched domain and the InternetProtocol Multimedia (IM) domain.

The latter of these, the IM domain, makes sure that multimedia servicesare adequately managed. The IM domain supports the Session InitiationProtocol (SIP) as developed by the Internet Engineering Task Force(IETF).

SIP is an application layer signalling protocol for starting, changingand ending user sessions as well as for sending and receivingtransactions. A session may, for example, be a two-way telephone call ormulti-way conference session or connection between a user and anapplication server (AS). The establishment of these sessions enables auser to be provided with the above-mentioned services. One of the basicfeatures of SIP is that the protocol enables personal mobility of a userusing mobile UE by providing the capability to reach a called party(which can be an application server AS) via a single locationindependent address.

In this document the following abbreviations will be used:

-   AS Application Server-   BGCF Breakout Gateway Control Function-   CN Core Network-   CPS Connection Processing Server-   CS Circuit Switched-   CSCF Call Session Control Function or Call State Control Function-   DNS Domain Name System-   ENUM See “E.164 number and DNS” (RFC2916)-   FQDN Fully Qualified Domain Name-   GW/S/AS network function or entity e.g. a proxy and/or Gateway    and/or Server and/or Application Server or the like-   HSS Home Subscriber Server-   I-CSCF Interrogating CSCF-   ID Identity-   IM IP Multimedia-   IMS IP Multimedia core network Subsystem-   IMS-WV-GW Gateway between IMS and WV networks-   IP Internet Protocol-   ISC IP multimedia Service Control-   MGCF Media Gateway Control Function-   NAPTR Naming Authority Pointer (RFC-2915)-   O-CSCF Outbound CSCF.-   P-CSCF Proxy CSCF-   PMG Presence (P), Messaging (M) and Group Management (G)-   PLS Presence List Server-   PS Presence Server-   PMG-WV-GW Gateway between IMS and WV networks-   RR Resource-Record of DNS-   S-CSCF Serving CSCF-   SIP Session Initiation Protocol (RFC 3261)-   SIP URI SIP Uniform Resource Identifier (RFC 3261)-   SLF Subscription Locator Function-   SSR Service and Subscription Repository-   TEL URL Is an URL associated to a terminal that can be contacted    using the telephone network (RFC2806)-   UE User Equipment-   UMS User Mobility Server-   UMTS Universal Mobile Telecommunications System-   URI Uniform Resource Identifier-   URL Uniform Resource Locator-   WV Wireless Village

Terminating sessions/transactions are routed in an IMS from the I-CSCFto an S-CSCF that can route-them to an AS following the rules of afilter criteria. If the target identity (i.e. public user identity) isnot registered, the I-CSCF selects an S-CSCF, and the S-CSCF down loads(filter criteria from the HSS. However there is a problem where thetarget identity is not an IMS identity non-IMS identities are routedover the IMS network to a non-IMS network.

An AS originated session/transaction is routed in IMS from AS to anS-CSCF that can route them further. Normally this S-CSCF is the one thatwas used when the session/transaction was routed from S-CSCF to AS, oraddress of the S-CSCF that is returned from the HSS or other database asresponse to a query, or address of the (default) S-CSCF may beconfigured in AS or fetched from an internal or external database,table, list, configuration data storage or alike. There are cases whereit is difficult or impossible to find an S-CSCF.

Here are some examples where it can be difficult to find a S-CSCF:

a) If the subscriber is not registered, possibly no S-CSCF is assignedto the subscriber (or more accurately to any public user identity of thesubscriber).

b) If the sending network element is a service server that routes asession/transaction on behalf of the user, there is a similar situationi.e. there may be no S-CSCF assigned to the user. (This kind of serviceserver is referred to as user dependent service server).

c) If a third party user uses a group identity as target address e.g. amessage is sent to a group by a user that is not the “owner” of thegroup identity, there is a problem in deciding which S-CSCF should beused when the group server sends a message to each member of the group.

d) If the sender is a service that has no connection to any user (i.e.the sender is a user independent service server). At least in this casethe AS has to choose an S-CSCF or use a default S-CSCF. Both solutionshave drawbacks. In the first one the AS has to perform functionalitiesof I-CSCF i.e. choose an S-CSCF. In the second one (i.e. if the defaultis used), the problem is how the load is balanced (Round robinfunctionality in DNS may be used.)

An additional argument against routing through an S-CSCF is that noservice of S-CSCF is needed e.g. no filter criteria is utilized. This isespecially true in the user independent service server case.

Routing with service identities is another problem of IMS. In order toroute to an AS, server, gateway, network function, network entity oralike that hosts or offers the service, an entry is needed in SLF andHSS containing routing information (e.g. filter criteria) for routing toS-CSCF and from S-CSCF to the correct AS, server, gateway, networkfunction, network entity or the like that hosts or offers the service.The result is that HSS has to contain all service identities with properrouting information. There is a similar problem with group identitiescreated by users. A user may for example create a group of workcolleagues, a group of family and a group of friends. These identitieswith proper routing information have to be included in HSS. Serviceidentities may be quite stable but the group identities may be changedrelatively often. A group identity may be a list of users that can beused e.g. to send a message to all of them with a single message sendingprocedure (instead of repeating the procedure in order to send the samemessage to every one of them). The problem of using a service and groupidentity is the creation/modification/deletion of a more or lesstemporary entry in HSS in order to make the routing possible via anS-CSCF to a proper AS, server, gateway, network function, network entityor alike.

It has also been found that when a Presence List Server (PLS) subscribesto the presence information of presentities, the routing done accordingto the current 3GPP IMS standard is not optimal. In addition, when thePLS (AS) initiates a request by itself, it is not defined how the PLS(AS) selects an S-CSCF.

There exists a problem that if a group server is seen as an applicationserver, an ISC interface should be used. This has the disadvantage thatrouting is complicated in that an S-CSCF is needed in both theterminating and originating cases.

Another problem is that in known arrangements, the application serverhas to store all used service identities into an SLF, an HSS and/oranother subscriber database.

SUMMARY OF THE INVENTION

It is an aim of embodiments of the present invention to address one ormore of the problems described.

According to one aspect of the invention, there is provided a method ofrouting for a message via an IMS system comprising the steps ofreceiving a message at an I-CSCF, obtaining address information for anetwork function for which said message is intended and sending saidmessage to said network function accordance with said addressinformation.

The network function may be provided by a network entity. The networkfunction may be an application server, server, gateway or any othersuitable entity.

Preferably, said message is sent directly or via a proxy or gatewayelement to the network function via a gateway element.

Preferably, said obtaining step comprises querying a database.

Preferably, said database comprises a SLF.

Preferably, said database provides said address information for saidnetwork function.

Preferably, said database provides information identifying a furtherdatabase.

Preferably, said further database may comprise one of a HSS, UMS or SSR.

Preferably, said further database contains said address information.

Preferably, said further database contains configuration information ofsaid network function.

Preferably, the method comprises the step of determining if said messageis for an IMS target or a non-IMS target.

Preferably, said steps are followed only if it is determined that saidmessage is not routed to any S-CSCF because the said message is for anon IMS target, or for an IMS target that identifies a service or agroup or the like.

According to one aspect of the invention, there is provided a method ofrouting a message from a network function via an IMS system comprisingthe steps of:

originating a message from a network function;

determining the address of a proxy entity to which said message is to besent;

routing said message to said proxy entity; and

routing said message from said proxy entity to an entry point of atarget network.

Preferably, said entry point is in the same or different network as saidnetwork function.

Preferably, wherein said originating step comprises originating one of asession and a transaction.

Preferably, said determining step comprises the step of querying one ofa database, table, file and a list.

Preferably, said determining step comprises determining the proxy entityfrom information contained in said network function.

Preferably the method comprises the step of determining the entry pointto which said message is to be routed.

Preferably, said proxy entity is arranged to determine the entry pointto which said message is to be sent.

Preferably, said proxy entity is arranged to determine the I-CSCF towhich said message is to be sent by accessing a database.

Preferably, said database comprises a DNS.

According to one aspect of the invention, there is provided a method ofrouting a message from a network function via an IMS system comprisingthe steps of originating a message from a network function determiningthe I-CSCF to which said message is to be sent, routing said messagedirectly to said I-CSCF if said I-CSCF is in a same network as saidnetwork function.

According to one aspect of the invention, there is provided a method ofrouting a message from a network function via an IMS system comprisingthe steps of originating a message from a network function, determiningthe I-CSCF to which said message is to be sent, routing said messagedirectly to said I-CSCF if said I-CSCF is in a trusted network.

According to one aspect of the invention, there is provided a method ofrouting a message from a network function via an IMS system, said methodcomprising the steps of sending a request from the network function toan I-CSCF, determining at the I-CSCF the S-CSCF to which a message fromsaid network function is to be sent and sending said message to thedetermined S-CSCF.

Preferably, said network function comprises a PLS.

Preferably, said determining step comprises querying a database.

Preferably, said determining step comprises querying a HSS.

According to one aspect of the invention, there is provided a method ofrouting a message from a first network function via an IMS system, saidmethod comprising the steps of sending a request from the first networkfunction to an I-CSCF, determining at the I-CSCF a second networkfunction to which a message from said first network function is to besent and sending said message directly from the I-CSCF to said secondnetwork function.

According to one aspect of the invention, there is provided a method ofrouting a message comprising the steps of receiving a message inaccordance with a first protocol, converting said message to a secondprotocol, querying a database using identification information in saidmessage to obtain new identification information and using said newidentification information to route the message to a proxy.

Preferably, said proxy is arranged to route said message.

Preferably, said proxy is arranged to obtain a translation of saididentity.

Preferably, said proxy routes the message to another network.

Preferably, the proxy routes the message to an I-CSCF.

Preferably, an I-CSCF is arranged to query said database.

Preferably, said I-CSCF is arranged to route said message to said proxy.

Preferably, an entity receiving said message is arranged to route saidmessage to said proxy.

Preferably, wherein said second protocol is SIP.

Preferably, said proxy is arranged to route said message to a gateway.

BRIEF DESCRIPTION OF FIGURES

For a better understanding of the present invention and as to how thesame may be carried into effect, reference will be made by way ofexample only to the accompanying drawings in which:

FIG. 1 shows a known method of normal terminating routing in an IMSsystem;

FIG. 2 a shows a method embodying the present invention of routing in anIMS system;

FIG. 2 b shows schematically routing with non-IMS schemes;

FIG. 2 c shows schematically routing from WV user equipment;

FIG. 2 d shows routing from WV domain to either WV or IMS domain;

FIG. 3 a shows a known method of routing in an IMS system, where thesession or transaction originates with the AS;

FIG. 3 b shows a method embodying the present invention in an IMSsystem, where the session or transaction originates with the AS;

FIG. 4 shows a signal flow of a further embodiment of the invention;

FIG. 5 a shows a first arrangement where routing is done with an O-CSCF;

FIG. 5 b shows a second arrangement where routing is done with anO-CSCF;

FIG. 5 c shows a third arrangement where routing is done with an O-CSCF;

FIG. 5 d shows a fourth arrangement where routing is done with anO-CSCF;

FIG. 6 a shows a known arrangement for routing where a group server isan application server and there is a subscriber initiated group session;

FIG. 6 b shows a known arrangement where a group server is anapplication server and there is a group server initiated group session;

FIG. 6 c shows a embodiment of the present invention where the groupserver is not an application server and there is a subscriber initiatedgroup session;

FIG. 6 d shows an example embodying the present invention where thegroup server is not an application server and the group server initiatesa group session;

FIG. 7 a shows an arrangement where a server offers subscriberindependent services, in the originating case;

FIG. 7 b illustrates where the server offers subscriber independentservices in the terminating case:

FIG. 8 a to c show three routing scenarios for requests that originatefrom a public service identity PSI, embodying the invention; and

FIG. 9 shows the flow of messages where the PSI is the originator,embodying the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present invention will be described in relation to aUMTS system in accordance with the so-called third generation standards.Reference is made to the following third generation partnership projectstandards which are hereby incorporated by reference. These documentsdescribe the IP multimedia system to which embodiments of the presentinvention are particularly applicable. However the embodiments of thepresent invention are also applicable to any other type of SIP network,regardless of whether or not it is an IMS network as well as to non SIPnetworks which may or may not be IMS networks.

3GPP TS 23.002: “Network architecture”.

3GPP TS 23.228: “IP multimedia subsystem; Stage 2”.

3GPP TS 24.229: “IP Multimedia Call Control Protocol based on SIP andSDP; Stage3”

3GPP 23.841 Presence Service; Architecture and Functional Description

3GPP 24.841 Presence based on SIP; Functional models, flows and protocoldetails

Embodiments of the present invention may use SIP. In order to provideaccess to the Internet and other IM services to users, protocols havebeen developed to assist in providing telephony and multimedia servicesacross the Internet. The session initiation protocol (SIP) is one suchprotocol which has been developed for controlling the creation,modification and termination of sessions with one or more parties. Thecall sessions may include e.g. Internet or other IP network telephonecalls, conferences or other multimedia services and activities. Thetransactions may include e.g. Internet or other IP network messaging,presence, group, and other multimedia services and activities.

SIP addressing follows the popular Internet convention of identifying auser by a unique address using Uniform Resource Locators (URL's) or asdefined in RFC3261 it is SIP URI. SIP signalling between two usersconsists of a series of requests and responses. A SIP transaction hasdual parties, the user agent client (UAC) who sends a request and a useragent server (UAS) who responds in reply to the request. The client andserver comprise the SIP user agent. In addition to this, SIP includesthe SIP network server which is the network device/s which handlesignalling associated with multiple calls.

As is known in the art an SIP invitation typically includes twomessages. It will be understood that there may be more messages thanonly these and that, in fact, in 3GPP there are more messages used.These are not discussed herein for the sake of brevity. The two messagesare an INVITE, initiated by the caller UAC and a 200 OK message from thecallee. This latter message is typically acknowledged by the callerafter which stage the parties may communicate according to parameterssent and received during signalling. Both the caller and callee can enda session by executing a BYE message. During an established session anew, set of parameters may be selected by either participant producing afurther INVITE message or by using some other SIP message.

In the following, references are made to application servers. Inalternative embodiments, the application server may instead be a networkfunction or entity e.g. a proxy or a gateway or a server or the like.

Embodiments of the invention aim to avoid finding a S-CSCF forsessions/transactions that do not need any actions or services offeredby the S-CSCFs but only routing to/from a GW/S/AS i.e. a networkfunction or entity e.g. a proxy and/or gateway and/or server and/orapplication server or the like. To do this routing is done directly fromI-CSCF to a proper GW/S/AS with the help of SLF and/or HSS that returnsaddress of the proper GW/S/AS. Embodiments of the invention can beapplied at least to the following cases:

a) routing of non-IMS schemes via IMS network to a non-IMS network (e.g.WV scheme)

b) routing of generic schemes to a correct network: to IMS or to non-IMS(e.g. PRES-presence and IM instant message schemes)

c) routing of service and group identities to a proper GW/S/AS

Generic schemes are protocol independent schemes specifying only theservice but not the protocol. For example “IM” specifies the service tobe “Instant Messaging” but not the used protocol that would e.g. be SIPin case of IMS. Respectively “pres” specifies the “Presence” service.

If non-IMS identities are not inserted into the SLF and/or HSS, it ispossible to use for example pseudo entries in the SLF and/or HSS tohandle the normal routing via the IMS network to an AS (i.e. from I-CSCFto S-CSCF (filter criteria) to AS). The filter criteria is needed in theS-CSCF to choose the correct AS to which to route the non-IMS identity.An example of routing non-IMS identities via an IMS to non-IMS networkare Wireless Village (WV) identities that are routed from I-CSCF to anS-CSCF and further to an AS or server that acts as gateway e.g.IMS-WV-GW (or IMS Gateway) to WV network. These are discussed in moredetail hereinafter.

Reference will now be made to FIG. 1 which shows how routing iscurrently carried out in known IMS systems with the signal flowindicated diagrammatically. At least some of the messages may be inaccordance with the SIP (session initiated protocol). These messages areshown in capitals.

An I-CSCF 100 receives a message in step S1 such as an initial INVITE orMESSAGE.

The I-CSCF 100 then sends a query to the SLF 102 in step S2 and the SLFreturns the address of the correct HSS 104. If there is only one HSS,SLF is not needed, and step S2 can be omitted.

In step S3, the I-CSCF 100 then sends a query to the identified HSS 104.The HSS 104 replies with the address of the correct S-CSCF 108 or thecapabilities of a needed S-CSCF. If needed, the I-CSCF selects anS-CSCF.

In step S4, the I-CSCF 100 routes the message to the S-CSCF 108. TheS-CSCF down loads routing information, (e.g. filter criteria for routingto application servers) if not yet downloaded.

In step S5, the S-CSCF 108 routes the message to the correct applicationserver 106 using the downloaded routing information.

Reference will now be made to FIG. 2 a, which shows the routing used ina first embodiment of the invention. In particular, the routing ofnon-IMS schemes and service/group identities and dynamic identities isshown. It should be appreciated that in FIG. 2 a, the routing ofterminating sessions/transaction from the I-CSCF to the GWI/S/AS areshown. The same reference numbers will be used for the same entities asshown in FIG. 1.

In step T1, the I-CSCF 100 receives a message such as initial INVITE orMESSAGE.

In step T2, the I-CSCF 102 makes a query to the SLF/HSS 102. The SLF/HSSreturns the address of the correct GS/S/AS 106. Optionally, the SLF/RSS102 may return the address of the database or server such as a HSS, UMSuser mobility server or SSR subscriber service router or repository ordatabase containing dynamic public user identities or databasecontaining dynamic service identities or other database. SLF/HSS denotesSLF, or HSS in the case there is no SLF.

In step T3, the I-CSCF 102 will optionally make a query to the database110 identified in step T2. It should be noted that the SLF may havereturned the actual address of the database or its configurationinformation or the like. The database will return the address of thecorrect GW/S/AS 106.

In step T4, the I-CSCF 100 routes the message to the correct GW/S/ASusing the address returned by the SLF/HSS, if provided, or if not fromthe database 110.

Non-IMS schemes are other schemes than those associated with the user,group or service identities of IMS i.e. currently “sip” and “tel”, whichare also the originally used schemes in IMS. “Non-IMS scheme” is used inembodiments of the invention to refer to schemes which are not currentlyIMS schemes. As the standard evolve, it is of course possible that acurrent so-called non-IMS scheme may become an IMS scheme. If a non-IMSscheme becomes an IMS scheme, embodiments of the invention may stillapply.

In embodiments of the invention, the following may be done:

-   -   1. Routing to the target IMS network with non-IMS scheme is done        normally only if the target operator allows it to be done.    -   2. Routing via the target IMS network to WV network is done by        routing directly from I-CSCF to PMG-WV-GW or any other IMS        gateway because non-IMS subscriber has        -   normally no entry in HSS        -   no filter criteria        -   nothing to do with IMS    -    IMS is thus only a routing path to WV network    -   3. No fallback if faulty scheme        -   Normally error is returned to UE        -   IMS does not normally correct the faulty scheme    -   4. wv:+3584022334455@domain,        -   im:+3584022334455@domain,        -   pres:+3584022334455@domain,        -   sip:+3584022334455@domain        -   are valid WV routable identities.        -   wv:+3584022334455 is valid WV identity in the domain in            question

When non-IMS scheme is present, it is normally checked whether thetarget operator will receive the message via SIP. To do this, e.g. a DNSquery is made with target domain name. It is asked for SRV records e.g.with _im._sip.operator.net. The answer might be e.g._im._sip.operator.net SRV 0. 0 5060 i-cscf.operator.net.

This answer indicates that “im” scheme is accepted with SIP protocol inthe port 5060 of the address “i-cscf.operator.net”.

The target operator may or may not allow messages using a non-IMSscheme. If the target operator allows the non-IMS scheme, a routableaddress is found with DNS query and the message will be routed to thataddress. The scheme is not normally modified.

If the target operator will not receive the non-IMS scheme, that is noroutable address is found with DNS query, the message will be routed tothe appropriate GW/S/AS e.g. PMG-WV-GW or IMS gateway. The filtercriteria are not used to find the correct GW/S/AS and the address ofGW/S/AS is configured in S-CSCF or is fetched from a table, list ordatabase or the like. This can be done using for example a routing tableas follows: schema target wv pmg-wv-gw.home.net pres pmg-wv-gw.home.netim pmg-wv-gw.home.net

When a non-IMS scheme is present, it is checked whether the messageshould be routed to a S-CSCF e.g. because the target identity is an IMSidentity. The I-CSCF makes a SLF and/or HSS query. The scheme may or maynot be carried over Cx and Dx interfaces (standardized). There may bedifferent ranges for different schemes or the schemes may be markedsomehow inside the subscriber data.

If the message should be routed to a S-CSCF for example the identity isfound to be an IMS identity in the SLF/HSS, the schema is handledaccording to the general principles of IMS and routing is as normalterminating case in IMS.

If the message should not be routed to a S-CSCF for example the identityis not found to be an IMS identity in SLF/HSS, the I-CSCF finds thecorrect GW/S/AS where the message is routed. The GW/S/AS address isreturned from SLF/HSS or the address of GWI/S/AS is configured inI-CSCF. No S-CSCF is involved. There may be a new interface betweenI-CSCF and GW/S/AS e.g. PMG-WV-GW or other IMS gateway.

Routing to WV is possible via target IMS domain.

Reference is made to FIGS. 2 b to 2 d which illustrate theabove-described scenario. Referring first to FIG. 2 b:

This is where there is an IMS ID. From the user equipment 500 a messageis sent in step D1 to the P-CSCF 502 which in turn sends a message instep D2 to the S-CSCF 506. Next, the S-CSCF makes a query with the DNS504 in step D3. In response to that query, the S-CSCF sends a message instep D6 to the I-CSCF 514. The I-CSCF 514 sends message in step D7 tothe SLF 508 and receives a reply. In the next step, the I-CSCF sends amessage to the HSS and receives a reply in step D8. In step D9, theI-CSCF 514 sends a message to S-CSCF 516. The steps D7 to D9 are asdescribed earlier as steps S2 to S4 in relation to FIG. 1.

Where there is a non-IMS ID, the following steps occur: in particular,steps D1, D2, D3, D6, D7 and optionally D8 are as described when thereis an IMS identity. The next step however is step D11 where the I-CSCF514 contacts the second PMG-WV-GW or IMS gateway 520. The second IMSgateway 520 sends a message to a second WV server 526 in step D12. Instep D14, the WV server 526 sends a message to WV user equipment 528.

Where routing is not possible via the target IMS, the route taken is thesame as steps D1 to D3 already described. However, the next step is thenD4 where the S-CSCF 506 sends a message to the first IMS gateway 522.The next step may either be step D5 or D5 b. In step D5, a message issent to a first WV server 524 which contacts the second WV server 526 instep D13. A message is sent in step D5 b directly from the IMS gateway522 to the second WV server 526. In both cases the next step will bestep D14 where the second WV server sends a message to the WV userequipment 528.

It should be appreciated that the gateway entities 522, 520 and PMG 518can all be regarded as proxies or servers, and for example applicationservers.

Reference is made to FIG. 2C which shows where the routing from the WVserver is configurable (based on the scheme and/or domain). Normally,routing via the WV is the first choice and routing to the IMS is thesecond choice. However, this may be reversed in some embodiments of thepresent invention.

Routing to the WV may be via the target IMS domain. This is a result ofthe DNS query at the outbound proxy O-CSCF. Routing after the outboundproxy is the same as described in relation to FIG. 2 b. Those elements,which are the same in FIG. 2 b, are marked with the same referencenumbers.

Where there is a routable URI, that is routing is possible via thetarget IMS, there are two options. The first one is where there is anIMS ID. In this case, routing from the first WV user equipment 528 a isthen to the first WV server 524 in step E1. The first WV server 524sends a message in step E2 to the first IMS gateway 522 which in turnssends a message in step E3 to the O-CSCF 530. The O-CSCF 530 sends amessage in step E4 to the DNS 504. In response to the informationreceived from DNS 504, the O-CSCF 530 sends a message in step E6 to theI-CSCF 516. The I-CSCF 516 obtains information from the SLF 508 in stepE7 and information from the HSS 510 in step E8. E8 may also be analternative to step E7 if there is no SLF. Next, the I-CSCF contacts instep E9 the S-CSCF 516 identified by steps E7 and/or E8.

Where there is a non IMS ID, steps E1, E2, E3, E4, E6 and E7 areperformed as described in relation to the IMS ID. Step E8 is optionaland/or an alternative to step E7 if there is no SLF. The next step isthen step E11 where the I-CSCF 516 contacts second IMS gateway 520. Instep E12, the second IMS gateway 520 contacts the second WV server 526.In step E14, the second WV server 526 contacts the second WV userequipment 528 b.

Where routing is not possible via the target IMS, the steps taken wouldbe steps E1, B2, E3 and E4. At that point, an error would be returned toWV server 524 that may for example try to route to the target WV server526.

Again, the first and second IMS-gateways 522 and 520 as well as PMGserver 518 may be proxies or servers, for example application servers.

Reference is made to FIG. 2 d which illustrates routing to WV/IMS viathe WV domain. Again, the same reference numerals are used for the sameentities. At the target WV server 526, it is checked whether the user isa WV user. Where the user is a non WV user the following steps occur.Firstly, in step F1, a message is sent from the source WV user equipment528 b to the first WV server 524. The first WV server 524 sends amessage in step F13 to the second WV server 526. The second WV server526 sends a message in step F12 to the second IMS gateway 520 which inturn sends a message to the I-CSCF 514 in step F11. The I-CSCF obtainsinformation from the SLF. 508 in step F7 and information from HSS 510 instep F8 as previously described.

Next, in step F9, the I-CSCF 514 sends a message in step F9 to theS-CSCF 516. The S-CSCF 516 sends a message in step F10 to the userequipment 512 or the PMG server 518.

Where a WV user 528 a is the target user, a much simpler routing occurs.The WV user equipment, which is the source, 528 b, sends a message instep F1 to the first WV server 524 which then sends a message in stepF13 to the second WV server 526. The second WV server 526 in step F14sends a message to the WV user equipment which is the target, that is WVUE 528 a.

Loop detection is needed in the I-CSCF or in the IMS gateway or WVserver routes to IMS gateway only messages with target identities of IMSor the IMS gateway changes the scheme to SIP to prevent further routingback to the WV network.

An example will now be given of information stored in the SLF in oneembodiment of the invention:

An entry in SLF may contain e.g. the following information:

a) Usual IMS entry to refer to the proper HSS:

john.smith@operator.net reference to HSS_(—)3

b) John Smith has also WV subscription. WV traffic is routed to WVnetwork through the gateway IMS-WV-GW:

wv:john.smith@operator.net reference to IMS-WV-GW

c) John Smith wants to receive Instant messages in WV network:

im:john.smith@operator.net reference to IMS-WV-GW

d) John Smith wants to offer his Presence information from IMS network:

pres:john.smith@operator.net reference to HSS_(—)3

e) John Smith has created a group (consisting of his fishing friends) tobe used e.g. with message services. For example anyone can send anInstant message to the whole group by sending it to the group identity:

fishingfriends.john.smith@operator.net reference to group_server

The entry to offer movie services also to customers from other networksmight contain the following information:

movies@operator.net reference to movie server

These are only examples of information. References to a HSS and to agateway or server must differ in order that the I-CSCF is able to actaccordingly: to make HSS query to the indicated HSS or to route themessage to the indicated gateway or server respectively.

Embodiments of the invention avoid allocating an S-CSCF to route non-IMSidentities over the IMS to non-IMS networks.

Advantages of the embodiments of the invention are:

a) No big influence on HSS because no filter criteria is needed.

b) No need to allocate an S-CSCF i.e. saves resources.

c) No influence on S-CSCF i.e. no need to have special scenarios forhandling non-IMS identities.

d) SLF can contain all non-IMS identities or as on option a pseudo entryonly for one or more groups of the non-IMS identities.

e) Operator can offer service to its IMS customers to prioritize IMS ornon-IMS services e.g. presence service is offered from the WV network(when the IMS subscriber also has WV subscription).

f) Group names and service names can be routed-directly to the correctGW/S/AS. They need no entry in HSS.

g) Routing to several GW/S/ASs is difficult. To solve the problemsdiscussed above, routing to one GW/S/AS is enough. Of course the SLF mayreturn several addresses if needed. These could be tried one afteranother until a GW/S/AS is found that accepts the message. Theseaddresses could also be used as a route through several GW/S/ASs.

Scheme can be “visible” in SLF and/or in HSS i.e. it is part of the keythat is used to identify entries in SLF and/or in HSS or every publicuser identity entry in SLF and/or in HSS indicates what are the validschemes with that public user identity.

A second embodiment of the present invention will now be described withreference to FIGS. 3 a and 3 b.

In order to avoid finding a S-CSCF for a session/transaction, where noS-CSCF is allocated or it is difficult to find out the address of theallocated S-CSCF, the session/transaction is routed from the GW/S/AS toan O-CSCF i.e. outbound proxy, From O-CSCF i.e. outbound proxy thesession/transaction is routed further to I-CSCF of the target network.

The O-CSCF i.e. the outbound proxy may be bypassed when the targetnetwork is the same network i.e. the target I-CSCF is located in thesame network or in a trusted network. In this case session/transactionis routed directly from GW/S/AS to the I-CSCF.

This embodiment of invention can be applied at least to the followingcases:

-   a) routing from GW/S/AS (e.g. from IMS WV gateway) non-IMS traffic    (e.g. with WV scheme) via IMS network to another IMS network-   b) routing from GW/S/AS sessions/transactions where the originator    (e.g. service group server) is loosely or not at all connected to    any subscriber; (in this case GW/S/AS is referred as user    independent service server)

GW/S/AS may start the session/transaction or GW/S/As may be a gatewaypassing traffic to IMS network. Both cases are referred here as GW/S/ASoriginated sessions/transactions.

In embodiments of the invention, the address or the name of the GW/S/AS,O-CSCF (i.e. outbound proxy) and I-CSCF may be configured in GW/S/AS.Addresses or names may also be fetched from a database (e.g. DNS),table, file, server or the like.

The addresses and names may be resolved e.g. with database (e.g. DNS),table, file, server or the like.

In general in all embodiments the addresses and/or names of thefunctions, gateways, servers, elements and the other entities of anetwork may be resolved e.g. with database (e.g. DNS), table, file,server or the like.

The O-CSCF is a logical functionality that may be implemented withI-CSCF in the same network element. Alternatively, the functionality ofthe I-CSCF may be changed so that it includes the functionality of theO-CSCF.

This embodiment is concerned with avoiding finding and/or allocating anS-CSCF to route GW/S/AS originated sessions/transactions.

Reference will now be made to FIG. 3 a which shows known routing in anIMS system.

In step A1, the GW/S/AS 204 originates a session or transaction. Thesession or transaction is routed to a S-CSCF 202. The address of theS-CSCF may be known from the previous session or transaction or it maybe queried from the HSS or it may be configured in the GW/S/AS. Possiblythe filter criteria are evaluated and the session or transaction may berouted to an As according to the filter criteria.

The next step is either step A2 a or A2 b. In step A2 b, the session ortransaction is routed to an I-CSCF 200 in the same network as theS-CSCF. In step A2 a, the session or transaction is routed to an I-CSCF206 in a different network to the S-CSCF 202.

Reference is now made to FIG. 3 b, which illustrates a second embodimentof the invention. In particular, the routing of non-IMS identities androuting of cases with IMS service/group identity as an originator isshown. It should be appreciated that in FIG. 3 b, the routing oforiginating sessions/transaction from the GW/S/AS to the O-CSCF (i.e.outbound proxy) are shown.

O-CSCF is an outbound proxy that may be like S-CSCF without subscriberdatabase, because the O-CSCF normally does not need to perform anyactivities associated to IMS subscribers. O-CSCF may have all otherfeatures of the S-CSCF.

In step B1 a, the AS 204 originates a session or transaction. Thesession or transaction is routed to O-CSCF 208. The address of theO-CSCF is queried from a database or the like or is fetched from atable, a file, a list or the like or is configured in the GW/S/AS.

Step B1 b is an optional step and allows optimal routing from theGW/S/AS 204 directly to the I-CSCF 200 if the I-CSCF is located in thesame network or in a trusted network.

The next step is either step B2 a or B2 b. In step B2 b, the O-CSCFroutes the session or transaction to a I-CSCF 200 in the same networkwhilst in step B2 a, the O-CSCF 208 routes the session or transaction toan I-CSCF 206 in another network.

Advantages of this second embodiment/of the invention are:

a) No influence on HSS, because there is no need to insert service/groupidentities (and possibly also filter criteria) to SLF and/or HSS inorder to be able to allocate an S-CSCF when a SW/S/AS originates asession/transaction on behalf of a service/group identity.

b) No need to allocate an S-CSCF i.e. saves resources.

c) No influence on S-CSCF. No scenarios needed to align SubscriberProfile Database (SPD) to handle these cases.

d) Sessions/transactions on behalf of service/group identities can berouted directly from GW/S/AS to O-CSCF without passing any S-CSCF.

e) The solution can be seen as a second (GW/S/AS to I-CSCF in the ownnetwork) and a third (GW/S/AS to O-CSCF) possibility to route GW/S/ASoriginated sessions/transactions. The first possibility is to route viaS-CSCF if the S-CSCF can easily be used.

When the Presence List Server (PLS) terminates some request and ittriggers a new request or some request is initiated by the PLS, in thecurrent 3GPP IMS architecture the PLS needs to send the request to anS-CSCF. This can be done based on the Record-Route header of thereceived request (if there was one) or the PLS can have the S-CSCFconfigured. In a better solution, the PLS can directly send the messageto an I-CSCF and leave out the S-CSCF as in case of PLS (group) thereare no originating services.

Public service URIs (i.e. URIs that are identities of services or alike)and group URIs (i.e. URIs that are identities of groups or alike) can berouted according to the embodiments of this invention. In the firstembodiment (i.e. in case where routing from I-CSCF to GW/S/AS) theSLF/HSS may return name or address of the GW/S/AS similarly as it doesin cases where routing with an non-IMS identity according to theembodiment. In the second embodiment (i.e. GW/S/AS originated case) themessages with a service URI or a group URI as an originator are routedto O-CSCF similarly as messages with non-IMS identity as an originatoraccording to the embodiment.

Reference will now be made to FIG. 4 to describe a further embodiment ofthe invention. Current 3GPP architecture requires unnecessary involvingof the S-CSCF where the S-CSCF selection is problematic or not optimal.

The advantage of embodiments of the invention is that this solutionworks in all cases and is simpler than the one that follows the current3GPP PMG architecture.

FIG. 4 shows the messages in embodiments of the invention. This can besummarised as follows:

Watcher agent in a UE subscribes to a presence list (SUBSCRIBE #1 fromUE-till PLS).

The request is answered (200 OK from PLS to UE).

PLS initiates a subscription to one of the presentities belonging to thelist (SUBSCRIBE #2 PLS till PS).

This can be sent through the S-CSCF or as proposed in embodiment of thisinvention, it can be directly sent to the I-CSCF

The answer to the subscription is routed back from PS to PLS

Reference is made to FIG. 4 which shows the signal flow in the thirdembodiment of the present invention. In step C1, a subscribe message issent from the user equipment 400 to the P-CSCF 402. In step C2 thesubscribe message is sent from the P-CSCF 402 to the S-CSCF 404. In stepC3 the subscribed message is sent from the S-CSCF 404 to the PLS(AS)406. The PLS(As) sends in step C4 a 200 OK message (which is a SIPacknowledgement message) back to the S-CSCF 404. In step C5, the S-CSCF404 sends the 200 OK message to the P-CSCF 402. The P-CSCF 402 sends the200 OK message in step C6 to the user equipment 400. The flow shown inFIG. 4 now shows two options.

The optimal signal flow will now be described as followed. The next stepis for a prescribed message to be sent in step C7 from the PLS (AS) 406to the I-CSCF 408. In step C8, there is a HSS query where the I-CSCF 408sends a query to the HSS 410 and receives a reply. The HSS will returnthe correct S-CSCF or the capabilities of a needed S-CSCF.

In the next step C9 a second subscribe message is sent from the I-CSCF408 to the S-CSCF 412. The S-CSCF will send the subscribe message to thePS 414 in step C10. The presence server 414 sends an acknowledgementmessage such as a 200 OK message in step C11 to the S-CSCF 412. TheS-CSCF 412 sends in step C12 a 200 OK message to the I-CSCF 408.Finally, the I-CSCF 408 sends a message in step C13 to the PLS (AS) instep 13. This message is the 200 OK message.

In a less optimal solution, step C7 is replaced by steps C7 a and C7 b.In those steps, the PLS (AS) 406 sends the second subscribe messagefirst to the S-CSCF 404 in step C7 a. In step C7 b, the S-CSCF 404 sendsthe subscribe message to the I-CSCF 408. Additionally, step C13 isreplaced by steps C13 a and step C13 b in this less optimal solution. Inthis less optimal solution, the I-CSCF 408 sends the 200 OK message instep C13 a to the S-CSCF 404. In step C13 b, the S-CSCF 404 sends the200 OK message to the PLS (AS). This second solution is less optimal inthat it is not clear to which S-CSCF to send the messages if the PLSgenerates the request by itself.

The implementation is simple, as the PLS (defined in 3GPP to be an AS)need to send the PLS originated requests to the I-CSCF instead of theS-CSCF.

Reference is now made to FIGS. 5 a to 5 d which show arrangements inwhich the outbound proxy is utilised to get a more optimal routing inthe case of number portability. The outbound proxy has the capability toact as a CSCF without subscriber profile database i.e. it does nothandle subscribers and thus no filter criteria connected to anysubscriber are down loaded from subscriber database e.g. HSS. Theoutbound proxy, which is here called outbound CSCF i.e. O-CSCF, iscapable of making the ENUM translation. It can also route to similarlyas a S-CSCF. The O-CSCF can be used to solve number portability routingproblem with proposed solution where MGCF should route directly toanother network; and I-CSCF routes directly to an I-CSCF in anothernetwork.

In embodiments of the invention, the MGCF routes the session/transaction(with the new identity returned from number portability database e.g.SLF) to an O-CSCF. The O-CSCF checks the identity to see whether ENUMtranslation is needed. If it is, the O-CSCF performs the translation. Inshort the O-CSCF does all the same procedures as S-CSCF when it routessession/transaction to another network. The main difference betweenS-CSCF and O-CSCF is the usage. S-CSCF is used when there exists a userin the same network who can be linked to the session/transaction; whileO-CSCF is used when such a user cannot be found. In the CS originatedcase the calling party is not a subscriber of the IMS network. Becausethe target number is ported to another network neither is the calledparty is a subscriber of the network. Thus with using O-CSCF it ispossible to avoid routing through S-CSCF, and also to avoid adding newfunctionalities to MGCF in order to make it capable of routing directlyto another network.

One modification is to let the I-CSCF route the session/transactiondirectly to O-CSCF instead of MGCF routing to O-CSCF. The decisionprocedure in I-CSCF is simple: because the new identity (after thenumber portability procedure) is not identity of this network, thesession/transaction has to be routed out of this network to the targetnetwork. Thus routing to an O-CSCF is an evident choice. No S-CSCF canbe naturally chosen, because the new identity is not linked to anyidentity that could be registered in this network.

The same solution can be applied also to cases where number portabilityprocedure is done in the terminating network and the session/transactionis received from another IMS network.

In FIGS. 5 a and 5 b, porting to the IMS domain is illustrated.

The MGCF 500 receives a message from CS that is a call set up message instep G1. The MGCF 500 converts the message to a SIP message to forexample and initial INVITE message.

In step G2, the MGCF 500 sends the message to the I-CSCF 502 in the samenetwork which receives that message.

In step G3, the I-CSCF 502 makes a query to a number portabilitydatabase such as SLF 506 with the target number of the initial INVITEmessage.

In step G4, the SLF 504 returns the new identity.

In step G5, the I-CSCF 502 returns e.g. the “301 moved permanently”response to the MGCF 500.

In step G6, the MGCF reroutes the message to the O-CSCF 504.

In step G7, the O-CSCF 504 makes an ENUM translation of the new identityif it is or contains a number, for example E.164. This translationinvolves an ENUM entity 508.

In step G8, the O-CSCF 504 routes the message to a new I-CSCF 510 inanother IMS network.

Reference will now be made to FIG. 5 b, which shows a modification tothe arrangement of FIG. 5 a. Those elements which are the same as shownin FIG. 5 a are marked with the same reference numbers.

Steps H1 to H4 correspond to steps G1 to G4 of FIG. 5 a.

In step H5, the I-CSCF 502 routes the message to the O-CSCF 504.

Steps H6 and H7 correspond to steps G7 and G8 respectively.

Reference is now made to FIGS. 5 c and 5 d which illustrate porting to aCS domain.

Steps J1 to J7 correspond to steps G1 to G7 respectively.

In step J8, because the O-CSCF 504 is not able to get a routable SIPURI, the O-CSCF 504 routes the message to a first BGCF 514.

The next step is then J9 a or J9 b which constitute normal routingsteps. In particular, routing is either to a second BGCF 516 in step J9b or to a second MGCF 512 in step J9 a.

FIG. 5 d shows a modification to the arrangement of FIG. 5 c.

Steps K1 to K6 are the same as steps H1 to H6 respectively of FIG. 5 band steps K7, K8 a and K8 b correspond to steps J8, J9 a and J9 brespectively.

In embodiments of the invention, the SLF/HSS may be queried by theI-CSCF during a registration or session set-up to get the name of theHSS containing the required subscriber specific data or get the name ofthe an adaptation function such as an application server, gateway or thelike for further routing.

The notation SLF/HSS means SLF, or HSS if SLF does not exist. Theadaptation functionality is arranged to communicate with the CSCF andperforms protocol conversion between appropriate protocols' and the IMsubsystem control protocols if required. The adaptation functionality isarranged to act as a gateway or server where requests with non-SIPschemes may be routed. The SLF/HSS may be arranged to handle the schemesand return a SIP routable address as the name of the adaptationfunctionality.

In embodiments of the present invention, the I-CSCF can send a querye.g. DX_SLF_QUERY or alike to the SLF/HSS and includes as a parameterthe URI which is stated in the INVITE request. The SLF/HSS looks up inits database for the queried URI. The SLF answers with the HSS name inwhich the user's subscription data can be found or alternatively theSLF/HSS may answer with the name of the adaptation functionality wherethe request shall be routed.

The unknown status of a requested party can be determined in theSLF/HSS. The I-CSCF requests information on the user to be reached,identified by the URI included in the INVITE request and the SLF/HSSresponds back to the I-CSCF with an indication that the user is unknownif it can not find the queried URI. The I-CSCF uses the indication thatthe user is unknown returned from the SLF/HSS to formulate the correctSIP message back towards the originating party to indicate that the useris unknown.

Communications between the CSCF and adaptation functionality may be inaccordance with the SIP protocol. A single session control protocol maybe applied to the interface between the CSCF and the adaptationfunctionality. This may be the SIP protocol or another protocol.

In embodiments of the invention, the routing of SIP signalling withinthe IMS may use URIs. The CSCFs and adaptation functionality may beidentifiable using a valid SIP URL (host domain name or network address)on those interfaces supporting the SIP protocol. These SIP URLs may beused when identifying these nodes in header fields of messages.

Optionally SLF/HSS may return GW/S/AS address with a new identity. ThusSLF/HSS can be used as a portability network entity or device thatreturns a new identity with routing address.

A service URI is in the first place connected to a service. In thesecond place it may also be connected to an user (which has caused itscreation) for example because of charging. A service URI maybe used asan identity of the originator when originating a session/transaction onbehalf of a service. A user may create a group identity:

Type I (Subscriber Initiated Group Session or Transaction)

In this type of group session and transaction normally everybody payshis own session to group session or transaction. The procedure is thatthe user reserves a group identity from the group server. The user sendsthe group identity to members of the group and then the members initiatethe session or transaction to the group identity.

Type II (Group Server Initiated Group Session or Transaction)

In this type of group session and transaction normally the originatorpays all sessions to group session or transaction.

The procedure is that the user reserves a group identity from the groupserver. The user sends a list of members to the group server. The groupserver initiates the sessions or transactions to the group members.

This will now be described in more detail with reference to FIG. 6.FIGS. 6 a and 6 b describe known routing arrangements where the groupserver is an application server. These figures are included to aid theexplanation of embodiments of the present invention. FIGS. 6 c and 6 dillustrate embodiments of the present invention. In FIG. 6 c, therouting form the I-CSCF to the group server is as in FIG. 2 a. Therouting from the group server to the I-CSCF or to the O-CSCF is like therouting in FIG. 3 b.

Reference is made to FIG. 6 a which shows a Type I case. i.e. thesubscriber initiated group session or transaction. The originator 600sends in step 1 a message to the P-CSCF 602 which in step 2 contacts acorresponding S-CSCF 604. The S-CSCF contacts in step 3 the group server606. In step 4 the group server contacts the subscription database 608which can take any suitable form and may for example be an SLF, an HSSor a DRR (Dynamic Resource Register) or a database capable to storedynamic identities or alike. This effectively allows the originator 600to reserve a group identity. The group identity is stored or activatedin the subscriber database 608 by the group server 606 in step 4 and S.The group server returns the group identity to the originator 600 viathe S-CSCF 604 and the P-CSCF 602 in steps 6, 7 and 8 respectively. Theoriginator 600 connects to the network which contains to the groupserver 606.

The originator 600 then sends the group identity to the other members ofthe group, that is entity B, referenced 618 and entity C referenced 624.This is not shown. The originator 600 and entity B 618 both connect tothe network which contains the group server 606. Entity C 624 connectsto a different network to that containing the group server 606.

The members of the group, that is entity B 618 and entity C 624 initiatea session on the basis of the group identity. In step 21, each of themembers 618 and 624 contact a P-CSCF 616 and 622 respectively. Therespective P-CSCF contacts in step 22 a respective S-CSCF 614 and 620.The respective S-CSCF contacts in step 23 a common I-CSCF 612. It shouldbe appreciated that the P-CSCF and S-CSCF associated with entity B arein the same network as the group server while the P-CSCF and S-CSCFassociated with entity C are in a different network to the group server.

The I-CSCF 612 interrogates the subscriber database 608 to obtain therelevant S-CSCF, this taking place in steps 24 and 25. The I-CSCF 612then contacts the identified S-CSCF 610 in step 26. That S-CSCP thencontacts the group server 606. In this way, the session is initiated.

Reference is now made to FIG. 6 b which shows a type II case i.e. thegroup server initiated group session or transaction and the group serveris an application server. The elements which are the same as shown inFIG. 6 a are marked by the same reference numerals. The originator 600reserves a group identity in steps 1 to 8, these steps being the same orsimilar to those described in relation to FIG. 6 a. The originator thensends a list of members to the group server.

This is not shown. The group server then initiates sessions to themembers in steps 21 to 29 which will now be described. Again in thisexample the members are entity B 618 and entity C 624 with entity Bbeing connected to the same network which contains the group server andentity C being connected to a different network.

Firstly, the group server 600 contacts in step 21 to a S-CSCF 610. TheS-CSCF 610 contacts in step 22 to the subscriber database 608 to get theneeded subscriber information e.g. the originating filter criteriaassociated to the group identity. This information is returned in step23 to the S-CSCF 610. The S-CSCF 610 contacts the appropriate I-CSCF 612and 626. The I-CSCF 612 for the entity B user interrogates thesubscriber database in step 25 and receives information on the S-CSCF614 to be used for the group member B, in step 26. Likewise the I-CSCF626 for entity C 624, contacts a HSS 628 in step 25 which providedinformation in step 26 on the S-CSCF to be used.

The I-CSCFs 612 and 626 then contact the respective S-CSCF 614 andS-CSCF 620 for the respective members B and C 618 and 624. This happensin step 27. In step 28, the respective S-CSCFs 614 and 620 contactrespective P-CSCFs 616 and 622 associated with the respective members Band C 618 and 624. The respective P-CSCFs 616 and 622 then contact instep 29 the members B and C 618 and 624 respectively. In this way, thegroup server is able to initiate a session.

Reference is now made to FIG. 6 c which shows a type I case i.e. thesubscriber initiated group session or transaction where the group serveris not an application server. Instead, the group server may be a server.Again, those elements which are the same as shown in FIG. 6 a are markedwith the same reference numbers. In this arrangement, the group serveris referenced by 606′. Instead of a subscriber database, there is arouting database 608′. The difference between 608 and 608′ is the sameas between 102 and 104 of FIG. 1 (normal subscriber DB) and 102 and 110of FIG. 2 a. The routing database can be provided by an SLF and/or HSSand/or DRR.

In steps 1 to 8, the originator 600 reserves a group identity. Thesesteps are the same or similar to those described in relation to FIGS. 6a and 6 b. However, it should be appreciated that steps 4 and 5 may beomitted in embodiments of the present invention. In this case the groupserver 606′ may have the necessary group identity and not need to lookit up from the routing database or store it into the routing database.

The originator 600 then sends the group identity to the members of thegroup. Again, this is not shown. Next, the members of the group 618 and624 initiate a session to the group identity in steps 21 to 26. Steps 21to 25 are as described in FIG. 6 a except routing database 608′ is usedinstead of subscriber database 608. In practice there may be littledifference between a routing database and a subscriber database.However, a connection is made directly from the I-CSCF 612 to the groupserver 606′ in step 26. This may be as discussed in relation to previousembodiments.

Reference is made to FIG. 6 d which shows an example where the groupserver is not an application server and it is a type II case, i.e. thegroup server initiated group session or transaction. Again, thoseelements which are the same as in FIG. 6 a, b, and c are referred towith the same reference numbers.

The originator 600 reserves a group identity in steps 1 to 8. Again, aswith FIG. 6 c, steps 4 and 5 may be omitted. The originator then sends alist of members to the group server 606′. These steps are not shown forclarity.

The group server then initiates sessions with the members. Steps 21 to26 are an example where it is carried out with the identity of a memberin the group and the identity is SIP URI. This allows members attachedto the same network as the group server to be contacted to establish asession. This is illustrated by steps 21 to 26. In this, the groupserver 606′ connects directly to the I-CSCF 612, and not via an S-CSCF.This is as discussed in relation to earlier embodiments. The I-CSCF 612interrogates the routing database 608 in step 22 to receive routinginformation from the database in step 23. That routing information maybe the S-CSCF to which the message from the I-CSCF 612 is to be routed.Based on that routing information, the I-CSCF 612 contacts the S-CSCF614 associated with the user 618. This occurs in step 24. In step 25 theS-CSCF 614 contacts the P-CSCF 616 associated with the entity B 618. Instep 26, the P-CSCF 616 contacts the entity B 618. In this way, asession is initiated.

The group server may alternatively or additionally initiate sessions tothe member with a TEL URL of the own network. This allows membersattached to the same network as the group server to be contacted toestablish a session. In this step, the group server 606′ contacts instep 31 an O-CSCF 630. In step 32, the O-CSCF 630 looks up the ENUM froma database 632. This occurs in step 32 with the reply being sent to theO-CSCF in step 33. In step 34, the O-CSCF 630 contacts the I-CSCF 612.Steps 22 to 26 already described are then carried out. In this way, thesession can be established.

The group server can initiate a session alternatively or additionallywith a foreign TEL URL, that is with a TEL URL of a different network.This allows members attached to a different network as the group serverto be contacted to establish a session. In this, steps 31 to 34, alreadydescribed are carried out. However this case, step 34 would allow theO-CSCF 630 to contact the I-CSCF 626 associated with the member C 624.That I-CSCF 626 and member C are part of and connected to respectively adifferent network to that containing the group server. In step 35 theI-CSCF obtains routing information for the subscriber 624 from the HSS628. The information is returned in step 36. This information mayidentify the S-CSCF 620 to be used. The I-CSCF 626 then contacts theidentified S-CSCF 620 in step 37. In step 38 the S-CSCF 620 contacts therespective P-CSCF 622. The P-CSCF 622 contacts member C in step 39. Inthis way, a session is established.

Alternatively or additionally, the group server can initiate a sessionwith a member using a foreign SIP URI. In other words, the SIP URI of adifferent network is used. This allows members attached to a differentnetwork to the group server to be contacted to establish a session. Thisinvolves step 31 and then steps 34 to 39 already described. In otherwords, steps 32 and 33 are omitted.

In embodiments of the present invention the group server is not anapplication server so an ISC interface may not be used. In knownarrangements, an ISC interface is bound with a S-CSCF and AS, that isthere is an ISC interface between these entities. To route to an ASinvolves going via an ISC, that is S-CSCF to ISC to AS and vice versa. Afilter criteria is used at an S-CSCF to select and AS. In thisembodiment, the aim of the group server is to avoid the restriction thatthe routing to an AS must always go from the S-CSCF via the ISCinterface.

The point of the group server arrangement described in relation to FIGS.6 c and d and FIGS. 7 a and b, is:

a) Routing to group server is allowed from S-CSCF optionally with ISCand also via other interfaces in addition to the optional ISC (e.g. vianormal SIP).

b) Routing to group server is allowed also from other elements inaddition to the optional routing from S-CSCF in terminating cases.

c) Routing from group server is allowed also to other elements inaddition to the optional routing to S-CSCF in originating cases.

The group server is seen as an entry point to another network (which canbe regarded as the network offering group sessions).

The group server can be regarded as being an I-CSCF of another network.It is possible in some embodiments of the present invention, that agroup server can consist of application server and non applicationserver parts. Reserving group entity is routed as to an applicationserver whilst routing to the group identity is as routing to a server.Both routings of FIGS. 1 and 2 a are valid to the same server e.g.application server. This has the advantage that routing becomes simple.No S-CSCF involvement is required in cases where the group server isoriginator of the session. No. HSS involvement is necessary. The SLF canoffer addresses to the group server in the terminating case. SLF maycontain wildcard entries that are associated to the routing to a certaingroup server or servers. The group server(s) give(s) out i.e. deliver(s)only group addresses that match one of the wildcard entries in the SLF.This way group identities need no to be stored as dynamic identities tosubscriber database (e.g. HSS, DRR or alike). As an example*.john.doe@operator.net may be a wildcard entry in SLF (or in HSS ifthere is no SLF). When John Doe want to reserve a group identity, thegroup server gives to John Doe only group identities containing his ownidentity e.g. fishing-friends.john.doe@operator.net andfamily.john.doe@operator.net.

Reference is now made to FIG. 7 a which shows a server 606″ offeringsubscriber independent services. FIG. 7 a shows the originating casewhere routing is from the subscriber independent server. Those elementswhich were the same as shown in FIG. 6 are referred to as the samereference number. The same step number is used for those steps whichcorrespond to those shown in FIG. 6.

In the case where the users own SIP URI is used, steps 31, 34 and 22 to26 already described in relation to FIG. 6 are carried out in thatorder. In this case, instead of the group server or application servershown in FIG. 6, there is a subscriber independent server 606″. As inFIGS. 6 a and b, there is a subscriber database 608. In step 34, theO-CSCF contacts the I-CSCF 612 in the same network as contains theserver.

In some embodiments of the present invention, this can be optimised andsteps 21 to 26 can be carried out when the own SIP URI is used, leavingout steps 31 and 34.

If the network's own TEL URL is used, then steps 31 to 34 and steps 22to 26 are carried out in that order. In step 34, the O-CSCF contacts theI-CSCF 612 in the same network as contains the server.

If the ENUM translation fails, routing can still take place with the TELURL. In this case, steps 31 to 34 and 41 to 42 are used. In step 34, aBGCF 650 is contacted by the O-CSCF 630. The BGCF 650 contacts an MGCF652 in step 41 which in turn connects in step 42 to the circuit switcheddomain 654.

Routing can be done with a TEL URL of a foreign or different network.This involves steps 31 to 33 and 34 to 39 as described previously. Insteps 32 ENUM query is used to get information in step 33 to resolve theTEL URL into SIP URI to be used for routing. In step 34, the O-CSCFconnects to the I-CSCF 626 of the different network to that containingthe server 606″.

If routing is carried out with a SIP URI from a different network, thensteps 31 and 34 to 39 are carried out, in that order. In step 34, theO-CSCF connects to the I-CSCF 626 of the different network to thatcontaining the server 606″.

It should be appreciated that in some embodiments, one or more of theserouting methods can be carried out. For example, routing to differentusers can be carried out on this basis.

Reference is now made to FIG. 7 b which shows the terminating case.Again, those elements which are the same as shown in FIGS. 6 and 7 a arereferred to by the same reference number.

Where routing to the subscriber independent server 606″ is from the samenetwork as the server, the following steps are carried out in thisorder. In step 121, the user 618 contacts its associated P-CSCF 616which in turn contacts the appropriate S-CSCF 614 in step 122. In step123, the S-CSCF 614 contacts the I-CSCF 612. In step 124, the I-CSCF 612contacts the routing database which provides routing information in step125 to the I-CSCF 612 identifying the server 606″. In step 126, theI-CSCF contacts the subscriber independent server 606″.

In the terminating case where the user is in a different network to thesubscriber independent server 606″, the following steps are carried out:the user 624 sends contacts the P-CSCF 622 in step 131. The P-CSCF 622contacts the associated S-CSCF 620 in step 132. These elements areoutside the network containing the server 606″.

In step 133, the I-CSCF 612, in the same network as the server 606″ iscontacted by the S-CSCF 620′. Steps 124 to 126 are then performed, asalready described.

Where the user is in a circuit switched domain 654, the circuit switcheddomain 654 contacts the MGCF 652 in step 141. In step 142, the MGCF 652contacts the I-CSCF 612. Steps 124 and 126 are then carried out asalready described.

If a server handles all needed identities in its own database ordatabases, it is not dependent on the HSS or any other subscriberdatabase. For this reason, it can be referred to as a subscriberindependent server. In preferred embodiments of the present invention,the subscriber independent server may not be an application server so anISC interface may not be used. It can be regarded as being similar to anentry point to another network and can be looked on by the network ofwhich it is a part as if it were a I-CSCF of another network. Subscriberindependent server may be located physically also outside the network.All the required data concerning the subscribers is located in theserver itself or in its own database.

Embodiments of the present invention have the advantage that routingbecomes simple. No S-CSCF involvement is required in the cases where thegroup server is the originator of a session or a transaction. No HSSinvolvement is necessary. For example, the SLF can offer an address tothe server in the terminating case. All data concerning the subscriberscan be in the database of the subscriber independent server or in adatabase or databases connected to the server. The Sh i.e. the interfacebetween HSS and AS is not used. Sh interface may be used to get theS-CSCF address from the HSS in the case when an AS originates a sessionor transaction. If no S-CSCF is involved in the routing there is no needto ask HSS the S-CSCF address and thus no Sh interface is necessary.Embodiments of the present invention have the advantage that third partyoperators can easily offer originating and terminating services andthere is no need to insert anything into the HSS. The only change whichmay be required is to insert a domain name address pointing to theserver in the SLF. For example news.3-party-operators.operator.net maybe inserted to the SLF and connected to the routing to a subscriberindependent server, located e.g. in the address“news-host.newscompany.3-party-operators.operator.net” i.e. in thesubdomain 3-party-operators.operator.net. AB well the domain name may becompletely different from the operator's own domain name. For examplethe entry news.company.com may be inserted to the SLF and associated tothe routing to a subscriber independent server e.g. a news server of thecompany.com. In this way a third party operator may be able to offerservices to IMS subscribers without having to have its own IMS network.Thus embodiments of the invention, all needed data relating to thesubscribers may be located in the server itself or in its own databaseor databases or in databases operated by the same operator as theoperator of the server. This makes it possible for the third party tooffer services from its own server and to utilise the main (that is adifferent) operator's IMS or similar network for routing. Subscribers ofthe subscriber independent server may or may not also be IMSsubscribers. The third party operator is able to run its serverindependently of the main operator.

In one modification to the embodiments described, the outbound proxy isimplemented by a S-CSCF so that the originating AS sends a signal to theS-CSCF to act as an outbound proxy instead of a S-CSCF.

The signal sent by the AS is in the initial request

a) embedded in the address of S-CSCF e.g. it may be a parameter, a portnumber, a character or bit string in the user part of the address and/or

b) as a separate signal from the address of S-CSCF e.g. in a separateheader or in the payload.

Because the outbound proxy is only a subset of functionalities of S-CSCFit is simple to implement. With the same signalling mechanism, outboundproxy can be implemented with I-CSCF too, or with whichever CSCF.

The Release 6 version of the third generation partnership standard23.228, which is hereby incorporated by reference, introduces theconcept of a Public Service Identity (PSI). The arrangement discussedbelow uses the S-CSCF arranged to provide either a S-CSCF functionalityor a outbound proxy functionality.

With the introduction of standardized presence, messaging, conferencing,and group service capabilities in IM CN subsystem, there is a need forPublic Service Identities (PSIs). These identities are different fromthe Public User Identities in the respect that they identify services,which are hosted by application servers. In particular, Public ServiceIdentities are used to identify groups. For example a chat-type servicemay use a Public Service Identity (e.g. sip:chatlist_X@example.com) towhich the users establish a session to be able to send and receivemessages from other session participants.

Public Service Identities take the form of a SIP URL as defined in RFC3261 [12] and RFC 2396 [13] or the “tel:”-URL format as defined in RFC2806 [15]. These standards are hereby incorporated by reference and areIETF standards.

The IM CN subsystem provides the capability for users to create, manage,and use Public Service Identities under control of AS. It is possible tocreate statically and dynamically a Public Service Identity. Each PublicService Identity is hosted by an application server, which executes theservice specific logic as identified by the Public Service Identity. TheIM CN Subsystem provides a capability of routing IMS messages usingPublic Service Identity.

The routing of the AS originated sessions/transactions with PublicService Identity is not clear in the current proposals and thearrangements described below addresses this.

Up until now only the routing towards a PSI has been described, i.e.requests that terminate at the AS that provides the service. Embodimentsof the present invention discuss different possibilities for routing ofrequests that originate from a PSI.

Requests originating from a PSI are required e.g. when a Conference ASinvites a user to a conference (dial-out). As this example shows, theprogress of the conferencing work in CN1 is strongly related to the PSIrouting procedures.

For routing of requests that originate from a PSI, the followingpossible routing scenarios can be used:

a). Request Always Routed Via a S-CSCF in the Originating Home Network

In this case the AS 700 always has to route via the S-CSCF 704 of itshome network first.

This can be achieved by placing a so-called pre-loaded route header intothe request (standard SIP procedure). The routing is then from theS-CSCF 704 to the terminating I-CSCF 702,

b) Request Always Requires Routing Via Any CSCF in the OriginatingNetwork

Here the AS routes the initial request to either the I-CSCF 706 or theS-CSCF 704 of the home operator first. The particular CSCF can bedetermined either dynamically (e.g. over the Sh interface) or due tooperators policy.

c) Request Always Routed Directly to the Destination Network

The AS 700 in this scenario routes directly to the terminating I-CSCF702, without any involvement of a CSCF in the originating network. Thisis also inline with the routing procedures as described in SIP.

d) Request Routed Due to Operator Decision

Due to the possibility of having a pre-loaded route, it is not requiredto standardize one of the above scenarios as the only valid one forIMS—the routing behavior of the AS can be determined by operator basedon the policy of the home network.

Based on the provided service, an AS may or may not support specificrouting functionalities. SIP provides the possibility that an entity isonly able to route to a dedicated next hop, the so-called OutboundProxy. If an AS is not able to e.g. resolve the address of theterminating I-CSCF, it needs to forward the request first to an entitythat is capable of routing the request towards the terminating network.

This especially might be the case when the terminating party isindicated by a tel URL. In order to resolve a tel URL the AS could routethe request first to the S-CSCF, which is able to resolve tel URLs.

On the other hand it is very likely that many application servers willbe able to perform SIP routing procedures, DNS.

The functionality of the S-CSCF may need to be adjusted in order toprovide the necessary routing mechanisms for AS's; the S-CSCF shouldperform only its routing capabilities (and not e.g. the filteringcapabilities), when it detects that an incoming originating requestindicates a PSI as the originator.

Depending on the nature of services some charging support can already beprovided within the S-CSCF. However, the charging for specific servicesin IMS is not performed by the CSCFs, as they are designed to be serviceagnostic. If the charging support provided by the S-SCF is not enoughthe AS can provide more information for charging purposes.

Nevertheless, in the given example for a dial-out conference, theinvitation will also involve a media session between the AS and thecalled user. In this case the generation of charging information for thesession based on the SDP in the INVITE message—could be performed by theS-CSCF.

It has to be noted, that in this case, the S-CSCF would

-   -   a) need information about the user, to whom the PSI relates to        (e.g. conference creator)—the PSI itself does not include any        hint for the user who has to be charged;    -   b) not have any control over the media session itself (as e.g.        the P-CSCF/PCF has via the Go interface).

The operator might want to collect certain data from all calls thattraverse its network such functionality can be performed by e.g. anI-CSCF, in order not to use too much of the resources of the S-CSCFs.

As shown above, there might be cases where an operator wants to routePSI originated calls to a CSCF in its own network first, although SIPallows that the AS resolves the terminating I-CSCF and routes to itdirectly.

It is also clear, that the routing behaviour may be different for theindividual cases which calls for a certain level of flexibility inrouting:

-   -   a) the operator might want to force all AS's to route PSI        originated calls over one or more specific entities in its        network (strict policy);    -   b) the operator might want to force only certain AS's to route        PSI originated calls over one or more specific entities in its        network;    -   c) although the operator does not apply any routing policy, the        AS might not be able to perform SIP routing procedures and        therefore needs to contact the S-CSCF first;    -   d) although the operator does not apply any routing policy, the        AS might need to contact the S-CSCF in certain cases, e.g. when        ENUM cannot be performed by the AS (case-by-case routing);

Allowing such a flexible approach would on the other hand would deviatefrom some principles within IM CN Subsystem as it currently is, e.g.

-   -   a) if the operator applies a lose policy, the AS could route        directly to entities outside the home network, although there is        no interface defined for such purpose;    -   b) if the operator applies a lose policy, the As could route        directly to the BGCF (e.g. when inviting another user to a        conference);        -   c) if the operator does not force the AS to route over the            S-CSCF, the S-CSCF might not get aware of the media streams            that are originating from terminating at the home network;    -   d) the routing of calls originating from an AS/PSI would not be        strictly defined within the home network and based on the        individual case and operator policy, the routing behavior will        be different.

If the sessions/transactions are routed via the S-CSCF, the firstproblem is what S-CSCF should be used and second how to skip over thefilter criteria handling. This is illustrated by the arrangement shownin FIG. 9.

The AS 800 fetches the S-CSCF address from configuration data.

The AS sends a first message to the identified S-CSCF 802: INVITE X fromY (Y is the PSI identity) Route: psiscsf.home.net.

Because the Route contains the PSI indication, the S-CSCF 902 skips theevaluation/processing of the filter criteria. The S-CSCF 802 then sendINVITE X From: Y message to the I-CSCF 804.

Embodiments of the present invention have been described in relation toapplication servers. However it should be appreciated that embodimentsof the invention can also be used with gateways or any other entityespecially with an entity having the same or similar relationship as theapplication servers to other entities illustrated in the Figures and/oras described.

It should be appreciated that a number of different features have beendescribed and that is possible that some embodiments of the inventioncan combine different ones of these features.

It should be appreciated that in embodiments of the present invention,IMS is access independent. This means that any suitable access methodsuch as WLAN (wireless local area network) or the like can be used. IMSand PRES schemes offer a way to specify services without specifying theprotocol to be used to get services. These protocol independent schemesprovide a way to identify services.

1. A method of routing for a message via an IMS system comprising thesteps of: receiving a message at an I-CSCF; obtaining addressinformation for a network function for which said message is intended;and sending said message to said network function in accordance withsaid address information.
 2. A method as claimed in claim 1, whereinsaid message is sent directly to the network function via a proxy orgateway element.
 3. A method as claimed in claim 1, wherein saidobtaining step comprises querying a database.
 4. A method as claimed inclaim 3, wherein said database comprises a SLF.
 5. A method as claimedin claim 3, wherein said database provides said address information forsaid network function.
 6. A method as claimed in claim 3, wherein saiddatabase provides information identifying a further database.
 7. Amethod as claimed in claim 6, wherein said further database comprisesone of a HSS, UMS or SSR.
 8. A method as claimed in claim 6, whereinsaid further database contains said address information.
 9. A method asclaimed in claim 6, wherein said further database contains configurationinformation of said network function.
 10. A method as claimed in claim1, comprising the step of determining if said message is for an IMStarget or a non-IMS target.
 11. A method as claimed in claim 10, whereinsaid steps of claim 1 are followed if it is determined that said messageis for a non-IMS target.
 12. A method of routing a message from anetwork function via an IMS system comprising the steps of: originatinga message from an network function; determining the address of a proxyentity to which said message is to be sent; routing said message to saidproxy entity; and routing said message from said proxy entity to anentry point of a target network.
 13. A method as claimed in claim 12,wherein said entry point is in the same network as said AS.
 14. A methodas claimed in claim 12, wherein said entry point is in a differentnetwork to said AS.
 15. A method as claimed in claim 12, wherein saidoriginating step comprises originating one of a session and atransaction.
 16. A method as claimed in claim 12, wherein saiddetermining step comprises the step of querying one of a database,table, file and a list.
 17. A method as claimed in claim 12, whereinsaid determining step comprises determining the proxy entity frominformation contained in said function.
 18. A method as claimed in claim12, comprising the step of determining the entry point to which saidmessage is to be routed.
 19. A method as claimed in claim 12, whereinsaid proxy entity is arranged to determine the target entry point towhich said message is to be sent.
 20. A method as claimed in claim 19,wherein said proxy entity is arranged to determine the target entrypoint to which said message is to be sent by accessing a database.
 21. Amethod as claimed in claim 20, wherein said database comprises a DNS.22. A method of routing a message from a network function via an IMSsystem comprising the steps of: originating a message from a networkfunction; determining the I-CSCF to which said message is to be sent;routing said message directly to said I-CSCF if said I-CSCF is in a samenetwork as said network function.
 23. A method of routing a message froma network function via an IMS system comprising the steps of:originating a message from a network function; determining the I-CSCF towhich said message is to be sent; routing said message directly to saidI-CSCF if said I-CSCF is in a trusted network.
 24. A method of routing amessage from a network function via an IMS system, said methodcomprising the steps of: sending a request from the network function toan I-CSCF; determining at the I-CSCF the S-CSCF to which a message fromsaid network function is to be sent; and sending said message to thedetermined S-CSCF.
 25. A method as claimed in claim 24, wherein saidnetwork function comprises a PLS.
 26. A method as claimed in claim 24,wherein said determining step comprises querying a database.
 27. Amethod as claimed in claim 24, wherein said determining step comprisesquerying a HSS.
 28. A method of routing a message from a first networkfunction via an IMS system, said method comprising the steps of: sendinga request from the first network function to an I-CSCF; determining atthe I-CSCF a second network function to which a message from said firstnetwork function is to be sent; and sending said message directly fromthe I-CSCF to said second network function.
 29. A method as claimed inclaim 28, wherein said network function comprises a network entity. 30.A method as claimed in claim 28, wherein said network function comprisesone of application server, server and gateway.
 31. A method as claimedin claim 28, wherein said network function provides an adaptationfunctionality.
 32. A method of routing a message comprising the stepsof: receiving a message in accordance with a first protocol; convertingsaid message to a second protocol; querying a database usingidentification information in said message to obtain new identificationinformation; and using said new identification information to route themessage to a proxy.
 33. A method as claimed in claim 32, wherein saidproxy is arranged to route said message.
 34. A method as claimed inclaim 32, wherein said proxy is arranged to obtain a translation of saididentity.
 35. A method as claimed in claim 32, wherein said proxy routesthe message to another network.
 36. A method as claimed in claim 35,wherein the proxy routes the message to an I-CSCF.
 37. A method asclaimed in claim 32, wherein an I-CSCF is arranged to query saiddatabase.
 38. A method as claimed in claim 37, wherein said I-CSCF isarranged to route said message to said proxy.
 39. A method as claimed inclaim 38, wherein an entity receiving said message is arranged to routesaid message to said proxy.
 40. A method as claimed in claim 32, whereinsaid second protocol is SIP.
 41. A method as claimed in claim 32,wherein said proxy is arranged to route said message to a gateway.
 42. Amethod of routing for a message via an IMS system comprising the stepsof: sending a message to an I-CSCF from a network function based onaddress information obtained by said network function; obtaining addressinformation at said I-CSCF for said message; and sending said messagefrom said I-CSCF in accordance with said address information.
 43. Amethod as claimed in claim 1, wherein said network function comprises aserver, said server being arranged to send a message for at least oneuser via a S-CSCF and to send a message for a least one user via anI-CSCF.
 44. A server arrangement for providing a service via a networkto at least one entity, said server comprising: a server for offeringservices to at least one subscriber via said network; and a databasestoring information about said at least one subscriber.
 45. A serverarrangement as claimed in claim 44, wherein said database is part ofsaid server.
 46. An arrangement as claimed in claim 44, wherein saiddatabase is separate from said server.
 47. A server arrangement asclaimed in claim 44, wherein in use, said server is operatedindependently of said network
 48. A server arrangement as claimed inclaim 44, wherein said network is operated by a network provider andsaid server is operated by a service provider, said network provider andsaid service provider being different.
 49. A server arrangement asclaimed in claim 44, wherein said server and said database are operatedby a common service provider.
 50. A server arrangement as claimed inclaim 44, wherein said network is used for routing between said serverand at least one subscriber.
 51. A method of providing a service to asubscriber from a server via a network, said method comprising the stepsof: Providing service information for a subscriber, said serviceinformation being provided by a server arrangement, said serverarrangement comprising a server and at least one database containingsubscriber information; and Routing said service information via anetwork.
 52. A method as claimed in claim 51, wherein at least onedatabase is part of said server.
 53. A method as claimed in claim 51,wherein said server arrangement is operated by a service provider,different to an operator providing said network.
 54. A method as claimedin claim 51, wherein said network is an IMS network.
 55. A method asclaimed in claim 51, wherein said at least one subscriber is an IMSsubscriber.
 58. A call session control function, said call sessioncontrol function having a first mode in which said call session controlfunction provides a call session control function and a second mode inwhich said call session control function provides an outbound proxyfunction.
 59. A call session control function as claimed in claim 58,wherein said call session control function comprises one of a servingcall session control function, an interrogating call session controlfunction and a proxy call session control function.
 60. A call sessioncontrol function as claimed in claim 58, wherein said modes are selectedin response to a signal received by said call session control function.61. A call session control function as claimed in claim 60, wherein themode is controlled in response to information contained in an address ofsaid call session control function.
 62. A call session control functionas claimed in claim 60, wherein the mode is controlled in response toinformation provided separately from the address of said call sessioncontrol function.
 63. A call session control function as claimed inclaim 61, wherein said information is provided in at least one of aseparate header and payload.